0장. 한눈에 보기
출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 제이펍 2026) | 원서: Balancing Coupling in Software Design (Manning) · 입문판·PDF 재구성
코드는 C#입니다. 아직
class·this·ExecuteSql같은 말이 낯설어도 괜찮다. 각 예제의 주석을 따라 읽고, 막히면 아래쪽 C# 예제 읽기 부록만 보면 된다.이 책 큰 그림 4가지만
- 결합은 "연결"이다. 나쁜 게 아니다. 부품이 서로 연결돼야 시스템이 굴러간다.
- 문제는 연결이 얼마나 강한가다. 한 군데 고쳤더니 엉뚱한 데가 터지면 결합이 너무 강한 거다.
- 시스템이 무너지는 진짜 원인은 부품 수가 아니라 복잡성이다. 복잡성은 "머릿속이 얼마나 꽉 차는가"다.
- 그래서 "서로 가장 적게 아는 방식"이 기본 안전판이다. 이보다 정교하게 균형을 잡는 건 더 깊은 주제라, 지금은 몰라도 된다.
이 0장은 책 본문에 나오는 어려운 말을 미리 풀어 둔 곳이다.
뒤 장에서 막히면 여기로 돌아오면 된다.
용어집(0절)과 개념 척추가 전부다. 천천히 읽으면 된다.
0. 먼저 알아둘 말 (용어집)
이 절은 책 전체 용어의 단일 출처다.
본문 어디서 어려운 말이 나와도, 그 뜻은 전부 여기 적혀 있다.
각 용어는 [한 문장 뜻 + 일상비유 + C# 예] 3종으로 적었다.
아래 용어들은 모두 PDF 원문 1·2·3장에 실제로 나온 말이다.
결합 (Coupling)
한 문장 뜻 — 두 부품이 연결돼 있어, 한쪽이 변하면 다른 쪽이 영향받는 관계.
일상비유 — 손을 맞잡은 두 사람. 한 명이 걸으면 다른 한 명도 끌려간다. 손을 안 잡으면 같이 걸을 수가 없다.
C# 예 —
public class OrderService // 주문 흐름을 조정하는 서비스입니다. 어떤 협력 객체를 아는지가 결합을 만듭니다.
{
public OrderService(dynamic repo) // 생성자: 이 객체가 어떤 협력 객체를 기억할지 정합니다.
{
this.Repo = repo; // 주문 서비스가 저장소를 기억함 = 결합
}
}
var service = new OrderService(mysql_repo); // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
service.Repo.Save(order); // service 는 repo 없이는 주문을 저장하지 못함
시스템 (System) — 구성요소·상호작용·목적
한 문장 뜻 — 하나의 목적을 이루려고 서로 연결돼 함께 움직이는 부품들의 모임. 부품 하나하나는 구성요소, 부품끼리 협력하는 방식은 상호작용이다.
일상비유 — 시계. 톱니(구성요소)가 따로 있을 땐 부품 더미지만, 맞물려 돌면(상호작용) "시간을 알려주는 시계"(목적)가 된다.
C# 예 —
// 구성요소 + 상호작용 + 목적 = 시스템
var system = new Dictionary<string, object> // 이름-값 묶음입니다.
{
{ "parts", new[] { "order", "payment" } }, // parts 항목
{ "links", new[] { "order -> payment" } }, // links 항목
{ "goal", "결제 처리" }, // goal 항목
}; // 사전 초기화 끝
공유 수명주기 (Shared Lifecycle)
한 문장 뜻 — 두 부품이 함께 빌드·테스트·배포되는 정도.
일상비유 — 한집 사는 부부. 이사 한 번에 둘 다 짐 싼다. 가끔 보는 친구는 따로 산다.
C# 예 —
// using Payments; // charge 기능을 같은 배포 단위에서 가져온다는 뜻입니다.
static dynamic PlaceOrder(dynamic order) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
charge(order); // payments 가 바뀌면 이 코드도 함께 테스트·배포해야 함
}
공유 지식 (Shared Knowledge)
한 문장 뜻 — 한쪽이 다른 쪽의 속사정에 대해 알아야 하는 양.
일상비유 — 친구에게 부탁할 때 그 친구 집 구조까지 알아야 한다면 부담. 전화번호만 알면 끝이라면 가볍다.
C# 예 —
repo.ExecuteSql("INSERT INTO orders /* 구현 생략 */"); // SQL·테이블까지 안다 = 지식 많이 공유
repo.Save(order); // "저장한다"만 안다 = 지식 적음
인터페이스 (Interface, 통합 인터페이스)
한 문장 뜻 — 한 부품이 바깥에 "이건 이렇게 쓰세요"라고 내놓는 사용 약속(이름·입력·출력).
일상비유 — 식당 메뉴판. 주방 속사정은 몰라도 메뉴만 보면 주문할 수 있다.
C# 예 —
public class OrderRepo // 주문 저장소입니다. 내부 DB 방식은 숨기고 Save 약속만 밖에 보입니다.
{
public dynamic Save(dynamic entity) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
/* 구현 생략 */ // "save 라는 이름으로 entity 하나 받는다"는 약속
}
}
repo.Save(order); // 호출자는 내부 저장 방식을 몰라도 됨
모놀리식 vs 서비스 분리 (Monolith vs Service Separation)
한 문장 뜻 — 모든 기능을 한 덩어리로 묶어 통째로 돌리면 모놀리식, 독립적으로 돌고 따로 배포되는 작은 프로그램들로 쪼개면 서비스 분리.
일상비유 — 칸 안 나뉜 원룸(모놀리식) vs 침실·주방·욕실로 칸 나눈 집(서비스 분리). 욕실만 고쳐도 침실은 멀쩡하다.
C# 예 —
var payment_service_url = "http://billing:5000/charge"; // 결제는 따로 도는 별도 서버
request_payment(payment_service_url, order); // 네트워크로 다른 서비스에 요청
추상화 / 추상 메서드 (Abstraction / Abstract Method)
한 문장 뜻 — 구체적인 속사정은 숨기고 "무엇을 하는지"만 약속으로 남긴 골격.
일상비유 — "탈것"이라는 말. 자전거인지 차인지 안 밝히고 "이동 수단"만 가리킨다.
C# 예 —
public class IRepository // 저장 기능의 약속입니다. 호출자는 구체 DB를 몰라도 됩니다.
{
public void Save(object e) { /* 구현 생략 */; } // ...(말줄임표) = "여기 내용은 비워둠 = 약속만"
}
public class MysqlOrderRepo : IRepository // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
public dynamic Save(dynamic e) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
Console.WriteLine("MySQL에 저장"); // 구체 구현은 하위 클래스가 채움
}
}
상위 / 하위 (Upstream / Downstream)
한 문장 뜻 — 기능을 내주는 쪽이 상위, 그 기능을 받아 쓰는 쪽이 하위.
일상비유 — 식당(상위)이 음식을 내주고, 손님(하위)이 받아먹는다. 손님이 메뉴를 알아야지, 식당이 손님을 알 필요는 없다.
C# 예 —
var price = price_service.GetPrice(item_id); // price_service = 상위(제공)
var total = price * qty; // 이 코드 = 하위(소비)
캡슐화 경계 (Encapsulation Boundary)
한 문장 뜻 — 부품이 바깥에 보여줄 것과 숨길 것을 가르는 선.
일상비유 — 자판기. 버튼(보여줌)은 누르되, 안의 동전 통(숨김)은 못 만진다.
C# 예 —
public class OrderRepo // 주문 저장소입니다. 내부 DB 방식은 숨기고 Save 약속만 밖에 보입니다.
{
public dynamic Save(dynamic order) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
var column = this.ColumnName(); // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
Console.WriteLine($"{column} 컬럼에 저장"); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
}
public dynamic ColumnName() // 이 메서드의 입력과 출력이 공개 약속입니다.
{
return "items_json"; // 결과를 호출자에게 돌려줍니다.
}
}
필수 결합 vs 우연 결합 (Essential vs Accidental Coupling)
한 문장 뜻 — 시스템 목적상 꼭 필요한 연결이 필수 결합, 부주의로 얼떨결에 생긴 연결이 우연 결합.
일상비유 — 자동차에 엔진과 바퀴가 연결된 건 필수. 운전대에 묻은 커피 자국은 우연(없어야 좋다).
C# 예 —
order.Charge(payment); // 필수: 주문엔 결제가 꼭 필요
handler.Db.Execute("/* 구현 생략 */Col"); // 우연: 화면 코드가 DB 컬럼명을 직접 앎
변경 전파 (Change Propagation)
한 문장 뜻 — 한 곳을 고쳤을 때 그 영향이 연결된 다른 곳까지 줄줄이 번지는 현상.
일상비유 — 도미노. 하나 쓰러뜨리면 줄줄이 넘어간다. 적게 넘어갈수록 좋은 설계.
C# 예 —
handler.Db.Execute("INSERT INTO orders(items_json) VALUES (/* 구현 생략 */)"); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
report.Db.Execute("SELECT items_json FROM orders"); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
// 컬럼명 items_json 을 items 로 바꾸면 두 줄이 함께 깨짐 = 변경 전파
복잡성 / 인지 부하 (Complexity / Cognitive Load)
한 문장 뜻 — 사람이 시스템을 다룰 때 머릿속이 얼마나 꽉 차는가. 그게 곧 복잡성이다.
일상비유 — 처음 간 대형 마트. 물건이 어디 있는지 몰라 머리가 복잡하다. 단골 마트는 안 그렇다.
C# 예 —
// 한 메서드가 외부 7곳에 의존 → "뭘 고쳐야 하지?" 머리 폭발
static dynamic Process(dynamic order) // 이 메서드의 입력과 출력이 공개 약속입니다.
{
db.Save(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
api.Notify(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
sms.Send(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
email.Send(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
pay.Charge(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
cache.Clear(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
analytics.Track(order); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
}
필수적 복잡성 vs 우발적 복잡성 (Essential vs Accidental Complexity)
한 문장 뜻 — 풀려는 문제 자체에 들어 있는 어쩔 수 없는 복잡함이 필수적, 우리가 설계를 잘못해 얹어 버린 복잡함이 우발적.
일상비유 — 세금 계산은 원래 복잡하다(필수적). 그런데 영수증을 일부러 흘림체로 써서 더 못 알아보게 만들면 그건 우발적이다.
C# 예 —
var tax = compute_tax(income, region); // 세법 자체의 복잡함 = 필수적
var result = a if (b && ! c) || d else e; // 굳이 꼬아 쓴 줄 = 우발적
커네빈 (Cynefin) 프레임워크
한 문장 뜻 — 지금 상황이 "답이 뻔한지·전문가에게 물으면 되는지·실험해 봐야 아는지·일단 도망쳐야 하는지"를 갈라 주는 의사결정 분류표.
일상비유 — 길을 잃었을 때 "지도가 있나 / 길 아는 사람에게 물을까 / 직접 가 볼까 / 일단 위험에서 벗어날까"를 먼저 가르는 것.
C# 예 —
var domain = classify(situation); // clear / complicated / complex / chaotic
if (domain == "complex") // 조건이 참일 때만 아래 결정을 실행합니다.
{
run_small_experiment(); // 복잡한 상황은 작은 실험으로 배움
}
선형적 상호작용 vs 복잡한 상호작용 (Linear vs Complex Interaction)
한 문장 뜻 — 한 곳을 건드렸을 때 영향이 뻔히 보이면 선형적, 엉뚱한 데까지 예측 불가하게 번지면 복잡한 상호작용.
일상비유 — 기계식 시계는 기어가 많아도 어디를 돌리면 어디가 도는지 따라갈 수 있다(선형). 연쇄 정전은 따라갈 수 없다(복잡).
C# 예 —
var total = price * qty; // 입력 바꾸면 결과가 뻔함(선형)
deploy(); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
other_service_dies(); // 배포 한 번에 딴 서비스가 죽음(복잡)
자유도 (Degrees of Freedom)
한 문장 뜻 — 시스템 상태를 정하려면 따로따로 정해야 하는 값의 개수. 많을수록 상태가 폭발하고 다루기 어렵다.
일상비유 — 정사각형은 한 변 길이만 정하면 끝(자유도 1). 직사각형은 가로·세로 둘 다 정해야 한다(자유도 2). 정할 게 많을수록 헷갈린다.
C# 예 —
// 같은 규칙을 두 곳에 복사 → 둘이 어긋날 수 있음 = 자유도 ↑
static dynamic IsFreeShippingOrder(dynamic o) // 한 줄짜리 규칙도 호출자가 알게 되는 약속입니다.
{
return o.Amount > 100; // 계산 결과를 호출자에게 돌려줍니다.
}
static dynamic IsFreeShippingForShipping(dynamic o) // 한 줄짜리 규칙도 호출자가 알게 되는 약속입니다.
{
return o.Amount > 100; // 계산 결과를 호출자에게 돌려줍니다.
}
개념 척추
여기 8개는 책 전체를 관통하는 큰 줄기다.
각각 ①망가지는 장면 ②일상비유 ③비유·코드·위험 표 ④한 문장 정의 순서다.
척추 1 — 결합 = 연결
망가지는 장면
함수 하나 고쳤을 뿐인데 전혀 딴 데가 터진 적 있죠?
"여길 만졌는데 왜 저기가 죽지?" — 그게 둘이 연결돼 있다는 신호다.
이 연결이 바로 결합이다.
일상비유
손을 맞잡은 두 사람. 한 명이 걸으면 다른 한 명도 끌려간다.
손을 아예 안 잡으면? 같이 걸을 수가 없다. 연결 0이면 협력도 0이다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 맞잡은 손 | service.repo = mysql_repo |
한쪽 변경이 다른 쪽으로 끌려옴 |
| 손 안 잡음(연결 0) | 서로 호출 없음 | 협력 불가 = 시스템이 아님 |
한 문장 정의 — 결합은 두 부품이 연결돼 서로 영향을 주는 관계이며, 없애야 할 적이 아니라 시스템을 묶어 주는 접착제다.
척추 2 — 공유 수명주기 vs 공유 지식
망가지는 장면
"왜 작은 수정에도 전체를 다시 배포해야 하지?"
"왜 DB만 바꾸려는데 화면 코드까지 손대야 하지?"
앞은 함께 배포되는 문제(수명주기), 뒤는 서로 너무 많이 아는 문제(지식)다. 결합엔 이 두 종류가 있다.
일상비유
수명주기 = 한집 사는 부부. 이사 한 번에 둘 다 짐 싼다.
지식 = 친구 부탁. 전화번호만 알면 가볍고, 집 구조·일정까지 알아야 하면 무겁다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 한집 부부(수명주기) | from .payments import charge |
한쪽 고치면 전체 재배포 |
| 집 구조까지 앎(지식 많음) | repo.ExecuteSql("INSERT ...") |
DB 바꾸면 호출부도 깨짐 |
| 전화번호만 앎(지식 적음) | repo.Save(entity) |
거의 안 깨짐 |
한 문장 정의 — 결합의 세기는 함께 배포되는 정도(공유 수명주기)와 서로 알아야 하는 양(공유 지식) 두 가지로 결정된다.
척추 3 — 상위·하위 지식 흐름
망가지는 장면
상위 쪽 인터페이스를 살짝 바꿨더니, 그걸 쓰던 하위 코드들이 조용히 다 깨졌다.
하위는 자기가 깨지는 줄도 몰랐다. 왜? 지식이 한 방향으로만 흐르기 때문이다.
일상비유
식당(상위)이 메뉴를 내주고, 손님(하위)이 받아 주문한다.
메뉴가 바뀌면 손님은 알아야 한다(식당 → 손님). 하지만 손님이 바뀌어도 식당은 모른다. 흐름은 한 방향이다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 식당 = 상위(제공) | price_service.get_price(id) |
상위가 바뀌면 하위가 깨짐 |
| 손님 = 하위(소비) | 이 코드가 price_service 를 호출 | 손님 변경은 식당에 영향 없음 |
한 문장 정의 — 기능을 내주는 상위와 받아 쓰는 하위 사이에서 지식은 상위→하위 한 방향으로 흐르므로, 상위 인터페이스 변경이 가장 위험하다.
척추 4 — 캡슐화 경계
망가지는 장면
화면 코드가 DB 컬럼 이름을 직접 알고 있었다. 컬럼명 하나 바꿨더니 화면이 터졌다.
숨겨야 할 속사정이 바깥으로 새어 나와 있던 것이다.
일상비유
자판기. 우리는 버튼만 누른다. 안의 동전 통·배선은 안 보이고 만질 수도 없다.
만약 동전 통이 바깥에 노출돼 있다면, 통 위치만 바꿔도 사용자가 헷갈린다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 자판기 버튼(보여줌) | repo.Save(order) |
안전 — 속사정 안 드러남 |
| 노출된 동전 통(숨김 실패) | handler.db.execute("... items_json") |
컬럼명 바꾸면 화면이 깨짐 |
한 문장 정의 — 캡슐화 경계는 부품이 보여줄 것과 숨길 것을 가르는 선이며, 경계 밖으로 새어 나온 지식이 곧 우연 결합의 씨앗이다.
척추 5 — 필수 vs 우연 결합
망가지는 장면
"의존성은 무조건 줄여야 좋다"며 다 끊으려다, 정작 꼭 필요한 연결(주문→결제)까지 건드려 시스템이 멈췄다.
연결엔 꼭 필요한 것과 없어도 될 것이 섞여 있는데 구분을 안 한 탓이다.
일상비유
자동차에 엔진과 바퀴가 연결된 건 필수다. 운전대에 묻은 커피 자국은 우연이다.
지워야 할 건 커피 자국이지 엔진 연결이 아니다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 엔진-바퀴(필수) | order.Charge(payment) |
끊으면 시스템이 목적을 잃음 |
| 커피 자국(우연) | handler.db.execute("...") |
그대로 두면 변경이 줄줄이 깨짐 |
한 문장 정의 — 결합은 목적상 꼭 필요한 필수 결합과 부주의로 생긴 우연 결합으로 나뉘며, 우연 결합만 제거 대상이다.
척추 6 — 변경 전파
망가지는 장면
작은 수정 하나가 도미노처럼 번져 열 군데를 같이 고치게 만든 적 있죠?
연결이 강할수록 한 번 건드린 변경이 더 멀리, 더 많이 퍼진다.
일상비유
도미노. 첫 패를 쓰러뜨리면 줄줄이 넘어간다.
서로 적게 알수록(지식 적음) 넘어가는 패가 줄어든다. 그래서 "적게 아는 설계"가 안전하다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 도미노 줄줄이 | 컬럼명 바꾸자 호출부 다 깨짐 | 한 수정이 여러 곳으로 전파 |
| 떨어뜨려 둔 패 | repo.Save(order) 로 격리 |
전파 멈춤 — 한 곳만 고침 |
한 문장 정의 — 변경 전파는 한 곳의 수정이 연결된 다른 곳까지 번지는 현상이며, 공유 지식이 적을수록 전파가 줄어든다.
척추 7 — 복잡성 = 인지 부하
망가지는 장면
코드를 한참 들여다봐도 "뭘 어디서 고쳐야 하는지" 머릿속이 정리가 안 된다.
부품이 많아서가 아니다. 부품끼리 너무 얽혀, 한 조각만 봐서는 전체를 짐작할 수 없어서다.
그렇게 머리가 꽉 차는 느낌, 그게 복잡성이다.
일상비유
처음 간 대형 마트. 물건이 어디 있는지 몰라 머리가 복잡하다.
단골 마트는 부품(상품) 수가 같아도 머리가 안 복잡하다. 즉 복잡성은 개수가 아니라 내 머릿속 부담으로 정해진다.
| 비유 | 코드 | 위험 |
|---|---|---|
| 처음 간 대형 마트 | 한 메서드가 외부 7곳에 의존 | "어디부터 봐야 하지" 인지 부하 폭발 |
| 단골 마트 | 한 메서드가 입력·출력만 명확 | 머릿속이 가벼움 — 고치기 쉬움 |
한 문장 정의 — 복잡성은 사람이 시스템을 다룰 때 느끼는 인지 부하이며, 부품 수가 아니라 서로 얼마나 얽혔는가로 정해진다.
척추 8 — 선형적 vs 복잡한 상호작용
망가지는 장면
부품이 딱 5개뿐인데, 한 군데를 고치니 엉뚱한 데가 터지고 그게 또 다른 데를 터뜨렸다.
반대로 부품이 5천 개여도 어디를 고치면 어디가 영향받는지 손으로 짚을 수 있는 시스템도 있다.
차이는 상호작용이 따라가지는가다.
일상비유
기계식 시계는 부품이 많아도, 이 기어를 돌리면 저 기어가 도는 걸 눈으로 따라갈 수 있다(선형).
연쇄 정전 사고는 한 발전소가 꺼지자 옆이 줄줄이 꺼졌고, 아무도 그 길을 미리 못 봤다(복잡).
| 비유 | 코드 | 위험 |
|---|---|---|
| 시계 기어(선형) | total = price * qty |
영향이 뻔함 — 안심하고 고침 |
| 연쇄 정전(복잡) | deploy() 했더니 딴 서비스가 죽음 |
영향 예측 불가 — 실험해 봐야 앎 |
한 문장 정의 — 시스템이 무너지는 진짜 원인은 부품 수가 아니라, 한 곳의 변경이 예측 불가하게 번지는 복잡한 상호작용이다.
한 걸음 더 ▸ (지금 몰라도 됨)
지금은 단순 규칙 하나면 충분하다. 서로 아는 게 가장 적은 방식이 기본 안전판이다.
다만 "무조건 느슨하게 = 정답"은 아니다. 너무 추상화하면 정작 필요한 정보까지 가려질 때도 있다.
이건 더 깊은 주제라, 지금은 "적게 알수록 안전" 규칙 하나만 들고 가면 된다.
사이드박스 — 어원 한 조각 (흥미용)
결합(coupling)은 라틴어 copulare =
co(함께) +apere(고정), 즉 "함께 고정한다"에서 왔다.시계 기어, 자동차 엔진, 중력으로 묶인 별까지 — 세상 거의 모든 게 무언가와 결합돼 있다. 외워 둘 필요는 없다.
부록 박스 — 역사 원형 (참고용, 건너뛰어도 됨)
옛 저수준 언어(어셈블리 등)에서는 부품끼리 메모리 주소를 직접 공유해, 한 곳만 바뀌어도 전체가 깨지기 쉬웠다.
오늘날 추상화·인터페이스 같은 도구는 모두 "서로 덜 알게 만들어" 이 깨짐을 줄이려는 장치다. 이 책 본문 코드는 원서 맥락에 맞춰 C#으로 본다.
C# 예제 읽기 부록
입문판의 코드는 원서/교재의 C# 맥락을 존중합니다. 다만 이 책은 C# 문법 교재가 아니라 설계 감각을 익히는 책이므로, 아래 정도만 알고 읽으면 충분합니다.
1. class는 역할을 가진 부품입니다
public class OrderService // OrderService는 주문 일을 맡은 부품입니다.
{
private readonly OrderRepository repository; // 저장소 부품과 연결되는 지점입니다.
public OrderService(OrderRepository repository) // 생성자는 필요한 부품을 바깥에서 받습니다.
{
this.repository = repository; // 받은 저장소를 이 객체 안에 보관합니다.
}
}
class는 "주문 담당자", "결제 담당자"처럼 책임을 가진 부품입니다.private readonly는 바깥에서 함부로 못 바꾸게 감추는 보관함입니다.- 생성자에서 다른 부품을 받으면, 두 부품 사이에 결합이 생깁니다.
2. 메서드는 부품이 밖에 공개하는 행동입니다
public void Save(Order order) // Save는 외부가 호출할 수 있는 공개 행동입니다.
{
repository.Save(order); // 실제 저장 방식은 저장소 부품에게 맡깁니다.
}
public은 밖에서 부를 수 있다는 뜻입니다.void는 돌려주는 값이 없다는 뜻입니다.repository.Save(order)는 다른 부품에게 일을 부탁하는 연결입니다.
3. this는 "지금 이 객체"를 뜻합니다
public class Counter // 숫자를 세는 작은 부품입니다.
{
private int total; // 현재 숫자를 객체 안에 숨겨 둡니다.
public void Add() // 하나 증가시키는 행동입니다.
{
this.total += 1; // this.total은 지금 이 Counter의 total입니다.
}
}
this.total은 "내 안의 total"이라는 뜻입니다.- 같은 이름의 지역 변수와 객체 필드를 구분할 때 특히 유용합니다.
4. 인터페이스는 "어떻게"가 아니라 "무엇을" 약속합니다
public interface IOrderRepository // 저장소가 반드시 제공해야 할 메뉴판입니다.
{
void Save(Order order); // 저장한다는 약속만 있고, DB 종류는 드러내지 않습니다.
}
public class MySqlOrderRepository : IOrderRepository // MySQL로 약속을 구현한 저장소입니다.
{
public void Save(Order order) // 인터페이스의 약속을 실제 코드로 채웁니다.
{
Console.WriteLine("MySQL에 주문 저장"); // 예제라 출력으로 저장을 대신 표현합니다.
}
}
interface는 호출자가 기대해도 되는 공개 약속입니다.- 구현 클래스가 바뀌어도 호출자는
Save라는 약속만 알면 됩니다.
5. if는 설계 선택이 갈라지는 지점입니다
if (order.Total >= 50000) // 주문 금액이 기준 이상인지 확인합니다.
{
Console.WriteLine("무료 배송"); // 조건이 참일 때만 실행됩니다.
}
else
{
Console.WriteLine("배송비 부과"); // 조건이 거짓일 때 실행됩니다.
}
- 조건문은 정책이 코드에 박히는 곳입니다.
- 기준이 자주 바뀌면 별도 정책 객체로 빼는 편이 더 안전할 수 있습니다.
6. 리스트와 배열은 여러 값을 담는 상자입니다
var items = new List<string> { "책", "노트" }; // 주문 품목을 여러 개 담습니다.
items.Add("펜"); // 리스트에 새 품목을 추가합니다.
List<T>는 같은 종류의 값을 여러 개 담습니다.- 리스트를 통째로 넘기면 받는 쪽은 그 구조에도 결합됩니다.
7. 예제에서 /* 구현 생략 */은 일부러 비운 자리입니다
public void Charge(Payment payment) // 결제 부품과 연결되는 행동입니다.
{
/* 구현 생략 */ // 핵심 설명과 무관한 세부 결제 코드는 감췄습니다.
}
- 이 책의 코드는 실행보다 설계 지점을 보여 주는 목적입니다.
/* 구현 생략 */이 보이면 "여기에는 실제 업무 코드가 들어간다"고 읽으면 됩니다.
클릭하거나 Space를 눌러 뒤집기